Merchant quality ratings in a financial computer network

ABSTRACT

In one aspect, the present disclosure relates to a method for improving a financial computer network by providing merchant quality ratings, the method comprising: receiving, at a server device, card transaction data for a plurality of merchants; determining a first location associated with a first user device; identifying a first merchant having a location near the first location; calculating a merchant quality rating for the first merchant using the card transaction data; generating a first notification message comprising a risk assessment of the first merchant based on the merchant quality rating for the first merchant; and presenting the first notification message to a user of the first user device.

BACKGROUND

Banks and other financial institutions may do business with a largenumber of merchants. While most merchants are honest and fair whendealing with customers, other merchants may be disreputable or evendeceitful. For example, some merchants entice consumers to subscribe toa service by offering a “free” trial, while making it exceedinglydifficult for consumers to later cancel the subscription. Banks may beunable to protect consumers from all unscrupulous merchants as there isno clear line between merchants that engage in outright fraud versusmerchants that are merely disreputable.

SUMMARY

According to one aspect, the present disclosure relates to a method forimproving a financial computer network by providing merchant qualityratings, the method can include: receiving, at a server device, cardtransaction data for a plurality of merchants; determining a firstlocation associated with a first user device; identifying a firstmerchant having a location near the first location; calculating amerchant quality rating for the first merchant using the cardtransaction data; generating a first notification message comprising arisk assessment of the first merchant based on the merchant qualityrating for the first merchant; and presenting the first notificationmessage to a user of the first user device.

In some embodiments, receiving card transaction data can includereceiving card transaction data from a database coupled to the serverdevice. In some embodiments, receiving card transaction data comprisesreceiving individual card transaction data for a plurality of merchants,and wherein calculating the merchant quality rating for the firstmerchant includes calculating a dispute rate and return rate for thefirst merchant using the individual card transaction data. In someembodiments, generating the first notification message can includegenerating a message indicating at least one of: the dispute rate of thefirst merchant compared to dispute rates for one or more othermerchants; and the return rate of the first merchant compared to returnrates for one or more other merchants. In some embodiments, the one ormore other merchants can include merchants that conduct similar businessto the first merchant.

In some embodiments, identifying the first merchant having a locationnear the first location can include: sending the first location to anApplication Programming Interface (API) provided by a places services;receiving a response from the places service comprising placeinformation associated with the first location; and matching the placeinformation against a list of known merchants to identify the firstmerchant. In some embodiments, generating the first notification messagecan include generating a recommendation for using a virtual card number.In some embodiments, presenting the first notification message to theuser of the first user device can include sending a push notification tothe first user device.

In some embodiments, the method can include: determining a uniformresource locator (URL) associated with a website visited by a webbrowser of a second user device; identifying a second merchantassociated with the website URL; calculating a merchant quality ratingfor the second merchant using the card transaction data; generating asecond notification message including a risk assessment of the secondmerchant based on the merchant quality rating for the second merchant;and presenting the second notification message to a user of the seconduser device. In some embodiments, determining the website URL comprisesdetecting the URL by a plugin of the web browser. In some embodiments,identifying the second merchant comprises matching the website URLagainst a list of known merchant website URLs. In some embodiments,generating the second notification message comprises generating arecommendation for using a safe shopping mode browser extension.

According to another aspect, the present disclosure relates to a methodfor improving a financial computer network by providing merchant qualityratings, the method including: receiving a first location from alocation sensor of a first user device; sending a first request to aserver device, the first request including the first location; receivinga first notification message from the server device; and presenting thefirst notification message to a user of the first user device. Theserver device may be configured to receive card transaction data for aplurality of merchants, identify the first merchant as having a locationnear the first location, calculate the merchant quality rating for thefirst merchant using the card transaction data, and generate the firstnotification message comprising a risk assessment of the first merchantbased on the merchant quality rating for the first merchant.

In some embodiments, the server device is configured to receiving cardtransaction data from a database coupled to the server device. In someembodiments, the server is configured to receive individual cardtransaction data for a plurality of merchants, and calculate themerchant quality rating for the first merchant includes calculating adispute rate and return rate for the first merchant using the individualcard transaction data. In some embodiments, the first notificationmessage can include at least one of: the dispute rate of the firstmerchant compared to dispute rates for one or more other merchants; andthe return rate of the first merchant compared to return rates for oneor more other merchants. In some embodiments, the one or more othermerchants can include merchants that conduct similar business to thefirst merchant. In some embodiments, the method can include: sending thefirst location to an application programming interface (API) provided bya places services; receiving a response from the places serviceincluding place information associated with the first location; andmatching the place information against a list of known merchants toidentify the first merchant. In some embodiments, the first notificationmessage can include generating a recommendation for using a virtual cardnumber.

According to another aspect, the present disclosure relates to a systemfor improving a financial computer network by providing merchant qualityratings, the system including a processor and a non-volatile memory. Thenon-volatile memory may store computer program code that when executedon the processor causes the processor to execute a process operable to:receive, at a server device, card transaction data for a plurality ofmerchants; determine a first location associated with a first userdevice; determine a first merchant having a location near the firstlocation; calculate a merchant quality rating for the first merchantusing the card transaction data; generate a first notification messageincluding a risk assessment of the first merchant based on the merchantquality rating for the first merchant; and present the firstnotification message to a user of the first user device.

BRIEF DESCRIPTION OF THE DRAWINGS

Various objectives, features, and advantages of the disclosed subjectmatter can be more fully appreciated with reference to the followingdetailed description of the disclosed subject matter when considered inconnection with the following drawings, in which like reference numeralsidentify like elements.

FIG. 1 is a diagram of an illustrative system for providing merchantquality ratings, according to some embodiments of the presentdisclosure.

FIGS. 2 and 3 are flow diagrams showing processing that may occur withinthe system of FIG. 1, according to some embodiments of the presentdisclosure.

FIG. 4 is a block diagram of a user device, according to someembodiments of the present disclosure.

FIG. 5 is a block diagram of a server device, according to someembodiments of the present disclosure.

The drawings are not necessarily to scale, or inclusive of all elementsof a system, emphasis instead generally being placed upon illustratingthe concepts, structures, and techniques sought to be protected herein.

DETAILED DESCRIPTION

Embodiments of the present disclosure include systems and methods forpresenting merchant quality ratings to consumers. A merchant qualityrating may indicate how reputable a merchant is based on historicalcredit and/or debit card transactions associated with that merchant. Insome embodiments, a merchant quality rating may be calculated using datagenerated by a bank during in the course of processing card transactionsbetween the bank's customers and various merchants. A merchant qualityrating may be based on, for example, a merchant's dispute rate, i.e. thepercentage of transactions initiated by a merchant that are subsequentlydisputed by consumers. As another example, a merchant quality rating maybe based on a merchant's return rate, which is the percentage of amerchant's sales that are later refunded. In some embodiments, a mobileapp user can is presented with merchant quality ratings for businessesnear the user's location. In some embodiments, a web browser pluginautomatically presents a merchant quality rating when a user visits awebsite associated with a merchant.

FIG. 1 shows a system 100 for providing merchant quality ratings,according to embodiments of the present disclosure. The system 100 maybe part of a financial computer network that includes, for example,merchant computing devices, payment processor computing devices, andbank computing devices.

The illustrative system 100 may include one or more user devices 102coupled to a server device 104 via a computer network 106. A user device102 may include various hardware and software components configured toperform certain processing described herein. In some embodiments, a userdevice 102 is configured to execute one or more user applications (or“apps”) that can be, for example, downloaded from an app store. Asillustrated in FIG. 1, a user device 102 may include a location sensor102, an app 110, and a web browser 112. The location sensor 102 mayinclude a Global Positioning System (GPS) receiver or other device fordetermining the device's geolocation. The app 110 may be a banking app,e-commerce app, or any other type of app suitable for presentingmerchant quality ratings to a user. The web browser 112 may be astandalone app for browsing web pages, or may be a web browsingcomponent integrated into an operating system of the user device 102.

The illustrative server device 104 includes a merchant identificationmodule 116, a merchant quality rating module 118, and a user messagingmodule 120. Each of the server device modules 116-120 may includehardware and/or software configured to perform the correspondingprocessing described herein below.

The server device 104 may also include, or be operatively coupled to, adatabase 122. In the example of FIG. 1, database 122 may include amerchants table 123 and a transactions table 124. Merchants table 123may store information about a plurality of merchants known to the system100. For example, merchants table 123 may include a list of merchantnames and the geolocation of stores, offices, or other real estateassociated with each merchant. In some embodiments, merchants table 123stores information about websites associated with particular merchants.For example, merchants table 123 may store the uniform resource locators(URLs) of websites that are owned by, operated by, or otherwiseassociated with a merchant.

Transactions table 124 may store information about card transactionsassociated with particular merchants. For example, when a consumerpurchases goods or services from a merchant using a credit/debit card130, the merchant may submit a sales transaction may to the card-issuingbank's computer network 128, which is then processed and stored intransactions table 124. As another example, if a user returns goods to amerchant, a refund transaction may be submitted and processed by bankcomputer network 128 and stored in transactions table 124. As yetanother example, if a user disputes a card transaction with their bank,the bank may store information about the disputed transaction intransactions table 124. In some embodiments, a merchant's aggregatedispute rate and return rate may be calculated using individualtransaction data stored in transactions table 124 for a given timeperiod (e.g., the past 30 days, 60 days, 1 year, etc.). In someembodiments, such aggregate data may be stored in transactions table124.

Server device 104 may have direct access to card transaction data storedby the bank computer network 128. For example, database 122 may bedirectly accessed by both the bank computer network 128 and the serverdevice 104. In other embodiments, the server device 104 may obtain cardtransaction data using an internal/private API provided by the bankcomputer network 128. In either case, the system 100 may utilizeproprietary bank data to provide merchant quality ratings to users.

In some embodiments, the system 100 may be configured to provide“in-store” merchant quality ratings to a user. For example, the app 110may automatically display information about a merchant's quality ratingwhen the user approaches a store, office, or other physical locationassociated with a merchant. In some embodiments, app 110 may determinethe location of the device 102 using location sensor 108 and thenutilize a places service 126 to determine information about a store,office, or other physical place within the vicinity of the user device102. Places service 126 may be an external service, such as FOURSQUARE™,that provides an application programing interface (API) to lookup placesin the vicinity of a given geolocation. Places service 126 may returnvarious information about nearby places, such as the name of a business.In some embodiments, app 110 may include a software development kit(SDK) for directly issuing requests to the places service 126. In otherembodiments, the app 110 may send the device's location to the serverdevice 104 (e.g., to merchant identification module 116) which, in turn,issues requests to places service 126.

The place information returned by places service 126 may be matchedagainst a list of known merchants to identify if there is some nearbymerchant for which the system 100 can provide a merchant quality rating.In some embodiments, server device's merchant identification module 116may compare the place information against merchant information storedwithin merchants table 123. In some embodiments, the user device's app110 may compare the place information to merchant information storedwithin local storage 115. In some embodiments, merchant informationstored in database 122 may be synchronized with merchant informationstored in local storage 115.

Once a merchant is identified, the system 100 may determine acorresponding merchant quality rating using card transaction data storedfor that merchant. In some embodiments, the server device 104 maydetermine the merchant quality rating. For example, merchant qualityrating module 118 may query the transactions table 124 to determine amerchant quality rating for the identified merchant. In someembodiments, merchant quality rating module 118 may calculate a merchantquality rating dynamically using information stored in the transactionstable 124. In other embodiments, merchant quality rating may bepre-computed and cached within the database 112 or other memory. In someembodiments, the app 110 may be configured to determine the merchantquality rating locally using merchant information stored in localstorage 115. For example, aggregate merchant data (e.g., return rate anddispute rate) may be calculated by the server device 104 andsynchronized with the user device's local storage 115.

A merchant quality rating may be provided as numeric ranking or scorethat indicates how reputable the merchant is relative to othermerchants. In some embodiments, the merchant quality rating may includea numeric representation of the merchant's dispute and/or return raterelative to other merchants. In some embodiments, a merchant's qualityrating may be calculated based on a comparison of merchants that conducta similar type of business. For example, a retail store that sellshealth and beauty products may be compared to other retailers that sellhealth and beauty products, or to other retail stores in general.

The system 100 may generate a notification message comprising a riskassessment of the merchant based on the merchant quality rating. Forexample, a notification message may state “MERCHANT X has a dispute rate2 times higher than other health and beauty supply stores” or “MERCHANTY has a return rate 5 times higher than normal.” The notificationmessage may be presented to the user of the user device 102. In someembodiments, the message may be displayed within the app 110. In someembodiments, the server device's user messaging module 120 may cause apush notification to be sent to user device 102, the push notificationincluding the generated notification message for the merchant.

The system 100 may also be configured to provide a merchant qualityrating to a user when the user visits a website associated with a knownmerchant. In some embodiments, a browser plugin 114 may be installed onthe user device 102 and configured to detect when a website URL isvisited by the web browser 112. The system 100 may compare the URL to alist of known merchant website URLs associated with the visited website.In some embodiments, the server device 104 may identify a merchant basedon the URL. For example, the browser plugin 114 may send the visitedwebsite URL to merchant identification module 116 which in turn mayquery the merchants table 123 to identify a merchant associated withthat URL. In other embodiments, the user device 102 may identify themerchant locally, for example using merchant information stored/cachedwithin local storage 115. Once a merchant is identified, the system 100may determine a merchant quality rating and present a correspondingnotification message to the user, as described above.

In some embodiments, the system 100 may perform one or more remedialactions to reduce the risk that a “low quality” merchant may pose to theuser. A “low quality” merchant may be defined as a merchant having anumeric merchant quality rating that is below some predeterminedthreshold value. In some embodiments, the system 100 may recommend thatthe user uses a virtual credit/debit card number (in contrast to anactual card number) when transacting with the merchant. In someembodiments, the system 100 may recommend that the user install/activatea web browser extension that provides a “safe shopping” mode. A safeshopping browser extension can cause the web browser to not store anypersonally identifiable during the shopping session.

It will be appreciated that the system 100 may be provided as part of,or closely coupled to, a bank computer network 128. The system 100 mayrely on transaction data and other data that is uniquely available tobanks in order to provide accurate merchant quality ratings to users,including bank customers and non-customers.

Referring to FIG. 2, a method 200 may be used to provide “in-store”merchant quality ratings. Portions of the method 200 may be performed bya server device (e.g., server device 104 in FIG. 1) and/or by a userdevice (e.g., user device 102 in FIG. 1).

At block 202, card transaction data may be received for a plurality ofmerchants. The card transaction data may include individual credit/debitcard transactions or aggregate transaction data such as merchant disputerate and return rate. In some embodiments, the card transaction data maybe stored in a database coupled to the server device (e.g., withindatabase 122 in FIG. 1).

At block 204, the location of the user device may be determined, forexample using a GPS receiver or other location sensor within the userdevice. At block 206, a merchant is identified having a location nearthe user device's location. In some embodiments, a places service (e.g.,places service 126 in FIG. 1) may be used to retrieve information aboutnearby stores, offices, or other physical places in the vicinity of theuser device location. The place information may be matched against alist of known merchants (e.g., merchants table 123 of FIG. 1) toidentify a merchant near the user device.

At block 208, a merchant quality rating may be determined for themerchant based on the card transaction data. In some embodiments, themerchant quality rating may indicate whether the merchant has arelatively dispute rate or return rate higher compared to othermerchants. At block 210, a notification message may be generated, thenotification message comprising a risk assessment of the merchant basedon the merchant quality rating.

At block 212, the notification message may be presented to a user of theuser device. In some embodiments, the notification message may bedisplayed within an app running on the user device. In otherembodiments, the notification message may be sent as a push notificationto the user device.

In some embodiments, the method 200 may include perform one or moreremedial actions to reduce the risk that a “low quality” merchant maypose to the user. For example, a notification may be displayedsuggesting that the user use a virtual credit/debit card number (incontrast to an actual card number) when transacting with the nearbymerchant.

Referring to FIG. 3, a method 300 may be used to present a merchantquality rating when a user visits a website associated a merchant.Portions of the method 300 may be performed by a server device (e.g.,server device 104 in FIG. 1) and/or by a user device (e.g., user device102 in FIG. 1).

At block 302, card transaction data may be received for a plurality ofmerchants. The card transaction data may include individual credit/debitcard transactions or aggregate transaction data such as merchant disputerate and return rate. In some embodiments, the card transaction data maybe stored in a database coupled to the server device (e.g., withindatabase 122 in FIG. 1).

At block 304, in response to a user visiting a website within a webbrowser of the device, the website's URL may be determined (e.g., by abrowser plugin installed on the user device). At block 306, a merchantassociated with the website URL may be identified, for example bymatching the URL a list of known merchant website URLs (e.g., URLsstored within merchants table 123 of FIG. 1).

At block 308, a merchant quality rating may be determined for themerchant based on the card transaction data. In some embodiments, themerchant quality rating may indicate whether the merchant has arelatively dispute rate or return rate higher compared to othermerchants. At block 310, a notification message may be generated, thenotification message comprising a risk assessment of the merchant basedon the merchant quality rating.

At block 312, the notification message may be presented to a user of theuser device. In some embodiments, the notification message may bedisplayed within the web browser running on the user device.

In some embodiments, the method 300 may include perform one or moreremedial actions to reduce the risk that a “low quality” merchant maypose to the user. For example, a recommendation may be made to the userto install/activate a web browser extension that provides a “safeshopping” mode.

FIG. 4 shows a user device 400, according to an embodiment of thepresent disclosure. The illustrative user device 400 may include amemory interface 402, one or more data processors, image processors,central processing units 404, and/or secure processing units 405, and aperipherals interface 406. The memory interface 402, the one or moreprocessors 404 and/or secure processors 405, and/or the peripheralsinterface 406 may be separate components or may be integrated in one ormore integrated circuits. The various components in the user device 400may be coupled by one or more communication buses or signal lines.

Sensors, devices, and subsystems may be coupled to the peripheralsinterface 406 to facilitate multiple functionalities. For example, amotion sensor 410, a light sensor 412, and a proximity sensor 414 may becoupled to the peripherals interface 406 to facilitate orientation,lighting, and proximity functions. Other sensors 416 may also beconnected to the peripherals interface 406, such as a global navigationsatellite system (GNSS) (e.g., GPS receiver), a temperature sensor, abiometric sensor, magnetometer, or other sensing device, to facilitaterelated functionalities.

A camera subsystem 420 and an optical sensor 422, e.g., a chargedcoupled device (CCD) or a complementary metal-oxide semiconductor (CMOS)optical sensor, may be utilized to facilitate camera functions, such asrecording photographs and video clips. The camera subsystem 420 and theoptical sensor 422 may be used to collect images of a user to be usedduring authentication of a user, e.g., by performing facial recognitionanalysis.

Communication functions may be facilitated through one or more wiredand/or wireless communication subsystems 424, which can include radiofrequency receivers and transmitters and/or optical (e.g., infrared)receivers and transmitters. For example, the Bluetooth (e.g., Bluteoothlow energy (BTLE)) and/or WiFi communications described herein may behandled by wireless communication subsystems 424. The specific designand implementation of the communication subsystems 424 may depend on thecommunication network(s) over which the user device 400 is intended tooperate. For example, the user device 400 may include communicationsubsystems 424 designed to operate over a GSM network, a GPRS network,an EDGE network, a WiFi or WiMax network, and a Bluetooth™ network. Forexample, the wireless communication subsystems 424 may include hostingprotocols such that the device 400 can be configured as a base stationfor other wireless devices and/or to provide a WiFi service.

An audio subsystem 426 may be coupled to a speaker 428 and a microphone430 to facilitate voice-enabled functions, such as speaker recognition,voice replication, digital recording, and telephony functions. The audiosubsystem 426 may be configured to facilitate processing voice commands,voiceprinting, and voice authentication, for example.

The I/O subsystem 440 may include a touch-surface controller 442 and/orother input controller(s) 444. The touch-surface controller 442 may becoupled to a touch surface 446. The touch surface 446 and touch-surfacecontroller 442 may, for example, detect contact and movement or breakthereof using any of a plurality of touch sensitivity technologies,including but not limited to capacitive, resistive, infrared, andsurface acoustic wave technologies, as well as other proximity sensorarrays or other elements for determining one or more points of contactwith the touch surface 446.

The other input controller(s) 444 may be coupled to other input/controldevices 448, such as one or more buttons, rocker switches, thumb-wheel,infrared port, USB port, and/or a pointer device such as a stylus. Theone or more buttons (not shown) may include an up/down button for volumecontrol of the speaker 428 and/or the microphone 430.

In some implementations, a pressing of the button for a first durationmay disengage a lock of the touch surface 446; and a pressing of thebutton for a second duration that is longer than the first duration mayturn power to the user device 400 on or off. Pressing the button for athird duration may activate a voice control, or voice command, modulethat enables the user to speak commands into the microphone 430 to causethe device to execute the spoken command. The user may customize afunctionality of one or more of the buttons. The touch surface 446 can,for example, also be used to implement virtual or soft buttons and/or akeyboard.

In some implementations, the user device 400 may present recorded audioand/or video files, such as MP3, AAC, and MPEG files. In someimplementations, the user device 400 may include the functionality of anMP3 player, such as an iPod™. The user device 400 may, therefore,include a 36-pin connector and/or 8-pin connector that is compatiblewith the iPod. Other input/output and control devices may also be used.

The memory interface 402 may be coupled to memory 450. The memory 450may include high-speed random access memory and/or non-volatile memory,such as one or more magnetic disk storage devices, one or more opticalstorage devices, and/or flash memory (e.g., NAND, NOR). The memory 450may store an operating system 452, such as Darwin, RTXC, LINUX, UNIX, OSX, WINDOWS, or an embedded operating system such as VxWorks.

The operating system 452 may include instructions for handling basicsystem services and for performing hardware dependent tasks. In someimplementations, the operating system 452 may be a kernel (e.g., UNIXkernel). In some implementations, the operating system 452 may includeinstructions for performing voice authentication.

The memory 450 may also store communication instructions 454 tofacilitate communicating with one or more additional devices, one ormore computers and/or one or more servers. The memory 450 may includegraphical user interface instructions 456 to facilitate graphic userinterface processing; sensor processing instructions 458 to facilitatesensor-related processing and functions; phone instructions 460 tofacilitate phone-related processes and functions; electronic messaginginstructions 462 to facilitate electronic-messaging related processesand functions; web browsing instructions 464 to facilitate webbrowsing-related processes and functions; media processing instructions466 to facilitate media processing-related processes and functions;GNSS/Navigation instructions 468 to facilitate GNSS andnavigation-related processes and instructions; and/or camerainstructions 470 to facilitate camera-related processes and functions.

The memory 450 may store instructions 472 for one or more applicationsinstalled on the user device that determine and/or present merchantquality ratings to the user. For example, instructions 472 may includeinstructions corresponding to the app 110 and/or the browser plugin 114described above in the context of FIG. 1. The memory 450 may store othersoftware instructions 474 configured to perform processing describedherein.

Each of the above identified instructions and applications maycorrespond to a set of instructions for performing one or more functionsdescribed herein. These instructions need not be implemented as separatesoftware programs, procedures, or modules. The memory 450 may includeadditional instructions or fewer instructions. Furthermore, variousfunctions of the user device 400 may be implemented in hardware and/orin software, including in one or more signal processing and/orapplication specific integrated circuits.

In some embodiments, processor 404 may perform processing includingexecuting instructions stored in memory 450, and secure processor 405may perform some processing in a secure environment that may beinaccessible to other components of user device 400. For example, secureprocessor 405 may include cryptographic algorithms on board, hardwareencryption, and physical tamper proofing. Secure processor 405 may bemanufactured in secure facilities. Secure processor 405 may encryptdata/challenges from external devices. Secure processor 405 may encryptentire data packages that may be sent from user device 400 to thenetwork. Secure processor 405 may separate a valid user/external devicefrom a spoofed one, since a hacked or spoofed device may not have theprivate keys necessary to encrypt/decrypt, hash, or digitally sign data,as described herein.

FIG. 5 shows an illustrative server device 500 that may implementvarious features and processes as described herein. The server device500 may be implemented on any electronic device that runs softwareapplications derived from compiled instructions, including withoutlimitation personal computers, servers, smart phones, media players,electronic tablets, game consoles, email devices, etc. In someimplementations, the server device 500 may include one or moreprocessors 502, volatile memory 504, non-volatile memory 506, and one ormore peripherals 508. These components may be interconnected by one ormore computer buses 510.

Processor(s) 502 may use any known processor technology, including butnot limited to graphics processors and multi-core processors. Suitableprocessors for the execution of a program of instructions may include,by way of example, both general and special purpose microprocessors, andthe sole processor or one of multiple processors or cores, of any kindof computer. Bus 510 may be any known internal or external bustechnology, including but not limited to ISA, EISA, PCI, PCI Express,NuBus, USB, Serial ATA or FireWire. Volatile memory 504 may include, forexample, SDRAM. Processor 502 may receive instructions and data from aread-only memory or a random access memory or both. The essentialelements of a computer may include a processor for executinginstructions and one or more memories for storing instructions and data.

Non-volatile memory 506 may include by way of example semiconductormemory devices, such as EPROM, EEPROM, and flash memory devices;magnetic disks such as internal hard disks and removable disks;magneto-optical disks; and CD-ROM and DVD-ROM disks. Non-volatile memory506 may store various computer instructions including operating systeminstructions 512 and application instructions 514. Operating systeminstructions 512 may include instructions for implementing an operatingsystem (e.g., Mac OS®, Windows®, or Linux). The operating system may bemulti-user, multiprocessing, multitasking, multithreading, real-time,and the like. The operating system instructions 512 may include networkcommunications instructions, for example, software for implementingcommunication protocols, such as TCP/IP, HTTP, Ethernet, telephony, etc.Application instructions 514 can include instructions for determiningand/or presenting merchant quality ratings. For example, applicationinstructions 514 may include instructions for modules 116-120 describedabove in conjunction with FIG. 1. Application data 516 may correspond todata stored by the applications running on the server device 500. Forexample, Application data may 516 may include stored merchantinformation and/or stored card transaction data.

Peripherals 508 may be included within the server device 500 oroperatively coupled to communicate with the sever device 500.Peripherals 508 may include, for example, network interfaces 518, inputdevices 520, and storage devices 522. Network interfaces may include forexample an Ethernet or WiFi adapter. Input devices 520 may be any knowninput device technology, including but not limited to a keyboard(including a virtual keyboard), mouse, track ball, and touch-sensitivepad or display. Storage devices 522 may include one or more mass storagedevices for storing data files; such devices include magnetic disks,such as internal hard disks and removable disks; magneto-optical disks;and optical disks.

Methods described herein may represent processing that occurs within asystem for providing merchant quality ratings (e.g., system 100 of FIG.1). The subject matter described herein can be implemented in digitalelectronic circuitry, or in computer software, firmware, or hardware,including the structural means disclosed in this specification andstructural equivalents thereof, or in combinations of them. The subjectmatter described herein can be implemented as one or more computerprogram products, such as one or more computer programs tangiblyembodied in an information carrier (e.g., in a machine readable storagedevice), or embodied in a propagated signal, for execution by, or tocontrol the operation of, data processing apparatus (e.g., aprogrammable processor, a computer, or multiple computers). A computerprogram (also known as a program, software, software application, orcode) can be written in any form of programming language, includingcompiled or interpreted languages, and it can be deployed in any form,including as a stand-alone program or as a module, component,subroutine, or other unit suitable for use in a computing environment. Acomputer program does not necessarily correspond to a file. A programcan be stored in a portion of a file that holds other programs or data,in a single file dedicated to the program in question, or in multiplecoordinated files (e.g., files that store one or more modules, subprograms, or portions of code). A computer program can be deployed to beexecuted on one computer or on multiple computers at one site ordistributed across multiple sites and interconnected by a communicationnetwork.

The processes and logic flows described in this specification, includingthe method steps of the subject matter described herein, can beperformed by one or more programmable processors executing one or morecomputer programs to perform functions of the subject matter describedherein by operating on input data and generating output. The processesand logic flows can also be performed by, and apparatus of the subjectmatter described herein can be implemented as, special purpose logiccircuitry, e.g., an FPGA (field programmable gate array) or an ASIC(application specific integrated circuit).

Processors suitable for the execution of a computer program include, byway of example, both general and special purpose microprocessors, andany one or more processor of any kind of digital computer. Generally, aprocessor will receive instructions and data from a read only memory ora random access memory or both. The essential elements of a computer area processor for executing instructions and one or more memory devicesfor storing instructions and data. Generally, a computer will alsoinclude, or be operatively coupled to receive data from or transfer datato, or both, one or more mass storage devices for storing data, e.g.,magnetic, magneto optical disks, or optical disks. Information carrierssuitable for embodying computer program instructions and data includeall forms of nonvolatile memory, including by way of examplesemiconductor memory devices, such as EPROM, EEPROM, flash memorydevice, or magnetic disks. The processor and the memory can besupplemented by, or incorporated in, special purpose logic circuitry.

It is to be understood that the disclosed subject matter is not limitedin its application to the details of construction and to thearrangements of the components set forth in the following description orillustrated in the drawings. The disclosed subject matter is capable ofother embodiments and of being practiced and carried out in variousways. Also, it is to be understood that the phraseology and terminologyemployed herein are for the purpose of description and should not beregarded as limiting. As such, those skilled in the art will appreciatethat the conception, upon which this disclosure is based, may readily beutilized as a basis for the designing of other structures, methods, andsystems for carrying out the several purposes of the disclosed subjectmatter. It is important, therefore, that the claims be regarded asincluding such equivalent constructions insofar as they do not departfrom the spirit and scope of the disclosed subject matter.

Although the disclosed subject matter has been described and illustratedin the foregoing exemplary embodiments, it is understood that thepresent disclosure has been made only by way of example, and thatnumerous changes in the details of implementation of the disclosedsubject matter may be made without departing from the spirit and scopeof the disclosed subject matter.

1. A method for improving a financial computer network by providingmerchant quality ratings, the method comprising: receiving, at a serverdevice, card transaction data for a plurality of merchants, whereinreceiving card transaction data comprises receiving data for individualcard transactions from a card-issuing entity using a private ApplicationProgramming Interface (API); determining a first location associatedwith a first user device, the first user device operated by a first userassociated with the card-issuing entity; sending the first location fromthe server device to an API provided by a places service; receiving aresponse from the places service comprising place information associatedwith the first location; matching the place information against a listof known merchants to identify a first merchant; calculating a merchantquality rating for the first merchant using the card transaction data;generating a first notification message comprising a risk assessment ofthe first merchant based on the merchant quality rating for the firstmerchant; presenting the first notification message to the first user;determining a second location associated with a second user device, thesecond user device operated by second user not associated with thecard-issuing entity; identifying a second merchant associated with thesecond location; calculating a merchant quality rating for the secondmerchant using the card transaction data; generating a secondnotification message comprising a risk assessment of the second merchantbased on the merchant quality rating for the second merchant andpresenting the second notification message to the second user.
 2. Themethod of claim 1 wherein receiving card transaction data comprisesreceiving card transaction data from a database coupled to the serverdevice.
 3. The method of claim 1 wherein receiving card transaction datacomprises receiving individual card transaction data for a plurality ofmerchants, and wherein calculating the merchant quality rating for thefirst merchant comprises calculating a dispute rate and return rate forthe first merchant using the individual card transaction data.
 4. Themethod of claim 3 wherein generating the first notification messagecomprises generating a message indicating at least one of: the disputerate of the first merchant compared to dispute rates for one or moreother merchants; and the return rate of the first merchant compared toreturn rates for one or more other merchants.
 5. The method of claim 4wherein the one or more other merchants comprise merchants that conductsimilar business to the first merchant.
 6. (canceled)
 7. The method ofclaim 1 wherein generating the first notification message comprisesgenerating a recommendation for using a virtual card number.
 8. Themethod of claim 1 wherein presenting the first notification message tothe user of the first user device comprises sending a push notificationto the first user device.
 9. The method of claim 1 comprising:determining a uniform resource locator (URL) associated with a websitevisited by a web browser of a third user device; identifying a thirdmerchant associated with the website URL; calculating a merchant qualityrating for the third merchant using the card transaction data;generating a third notification message comprising a risk assessment ofthe third merchant based on the merchant quality rating for the thirdmerchant; and presenting the third notification message to a user of thethird user device.
 10. The method of claim 9 wherein determining thewebsite uniform resource locator (URL) comprises detecting the URL by aplugin of the web browser.
 11. The method of claim 9 wherein identifyingthe third merchant comprises matching the website URL against a list ofknown merchant website URLs.
 12. The method of claim 9 whereingenerating the third notification message comprises generating arecommendation for using a safe shopping mode browser extension, whereinthe safe shopping browser extension blocks the web browser from storingany personally identifiable information during the shopping session. 13.A method for improving a financial computer network by providingmerchant quality ratings, the method comprising: receiving a firstlocation from a location sensor of a first user device; sending a firstrequest to a server device, the first request comprising the firstlocation, wherein the server device is configured to: receive cardtransaction data for a plurality of merchants, send the first locationfrom the server device to an Application Programming Interface (API)provided by a places services service, receive a response from theplaces service comprising place information associated with the firstlocation, match the place information against a list of known merchantsto identify a first merchant, calculate the merchant quality rating forthe first merchant using the card transaction data, and generate a firstnotification message comprising a risk assessment of the first merchantbased on the merchant quality rating for the first merchant; receivingthe first notification message from the server device; and presentingthe first notification message to a user of the first user device. 14.The method of claim 13 wherein the server device is configured toreceiving card transaction data from a database coupled to the serverdevice.
 15. The method of claim 13 wherein the server is configured to:receive individual card transaction data for a plurality of merchants;and calculate the merchant quality rating for the first merchantcomprises calculating a dispute rate and return rate for the firstmerchant using the individual card transaction data.
 16. The method ofclaim 15 wherein the first notification message comprises at least oneof: the dispute rate of the first merchant compared to dispute rates forone or more other merchants; and the return rate of the first merchantcompared to return rates for one or more other merchants.
 17. The methodof claim 16 wherein the one or more other merchants comprise merchantsthat conduct similar business to the first merchant.
 18. (canceled) 19.The method of claim 13 wherein the first notification message comprisesgenerating a recommendation for using a virtual card number.
 20. Asystem for improving a financial computer network by providing merchantquality ratings, the system comprising: a processor; and a non-volatilememory storing computer program code that when executed on the processorcauses the processor to execute a process operable to: receive, at aserver device, card transaction data for a plurality of merchants;determine a first location associated with a first user device, thefirst user device operated by a first user; send the first location fromthe server device to an Application Programming Interface (API) providedby a places service; receive a response from the places servicecomprising place information associated with the first location; matchthe place information against a list of known merchants to identify afirst merchant associated with the first location; calculate a merchantquality rating for the first merchant using the card transaction data;generate a first notification message comprising a risk assessment ofthe first merchant based on the merchant quality rating for the firstmerchant; present the first notification message to the first user atthe first location; determine a second location associated with a seconduser device, the second user device operated by a second user; identifya second merchant associated with the second location; calculate amerchant quality rating for the second merchant using the cardtransaction data; generate a second notification message comprising arisk assessment of the second merchant based on the merchant qualityrating for the second merchant and present the second notificationmessage to the second user at the second location.